LGTM!

I was thinking a bit more about this, and I was wondering if we could use the same functional options pattern we use in the client to generate constructors for more complex variants, but I'm not sure f it would be worth it.

Like this?

rt, err := NewRouteTarget(WithTypeSubnet(/* Concrete struct here */))

More like:

rt, err := NewRouteTarget(RouteTargetTypeIp, WithRouteTargetValue("..."))

In this case it would be kind of silly because all variants have the same shape, but in a more complex struct, where different variants take different values, it could make sense:

v1, err := NewComplexEnum(ComplexEnumType1, 
    WithComplexEnumAttr1("I'm a string"), 
    WithComplexEnumAttr2(12),
)
// v1 is:
// ComplexEnum {
//     Value: ComplexEnumType1 {
//         Attr1: "I'm a string",
//         Attr2: 12,
//     }
// }


v2, err := NewComplexEnum(ComplexEnumType2, 
    WithComplexEnumAttr1("I'm a string"), 
    WithComplexEnumAttr3(true),
)
// v2 is:
// ComplexEnum {
//     Value: ComplexEnumType2 {
//         Attr1: "I'm a string",
//         Attr3: true,
//     }
// }

It has the same downsides of any functional options approach, with the added downside of requiring users to know which types match which option functions 😅

It has the same downsides of any functional options approach, with the added downside of requiring users to know which types match which option functions 😅

Haha. I feel that. That's why I do believe something that takes the entire concrete struct wouldn't be too bad, but at that point might as well eliminate a constructor and trust the user to set a field directly on the wrapper struct.

Thanks for sharing the examples! It helped me understand the approach. I think I agree that moving towards functional options for this is likely not worth it overall. We can, and should, revisit this if needed.